list: term ',' list { make_node(@item[0,1,3]) }
| term { $item[1] }
With attention on the actions, and assuming <autotree> is on.
In Perl 6, aside from the fact that there's a clearly better way to
write this rule, this would be translated:
rule list {
<?term> , <?list> { $0 = make_node('list', $?term, $?list) }
| <?term> { $0 = $?term }
}
The part that I'm complaining about in this mail is C<$0 = >. While
it's only three extra characters, I believe that it is a large hindrance
to readability. However, we can reclaim this readability by noticing
that the construct:
<{ get_rule() }> # call an anonymous rule returned by the code block
Can also be written:
<$( get_rule() )>
Because of the interpretation of:
<$somerule>
Therefore, the first syntax can be redefined to evaluate the code block
and assign the result to $0. The example now becomes:
rule list {
<?term> , <?list> <{ make_node('list', $?term, $?list) }>
| <?term> <{ $?term }>
}
My argument for using this notation stems from the fact that it would
be a royal pain to write subs like:
sub add ($a, $b) {
$RET = $a + $b;
}
Even though it's just a few extra characters. I don't want to think
about replacing the current parse tree node, I just want the rule to
represent a value. An assignment has little place there.
Luke
> <{ get_rule() }> # call an anonymous rule returned by the code block
>
> Can also be written:
>
> <$( get_rule() )>
>
> Therefore, the first syntax can be redefined to evaluate the code block
> and assign the result to $0. The example now becomes:
>
> rule list {
> <?term> , <?list> <{ make_node('list', $?term, $?list) }>
> | <?term> <{ $?term }>
> }
>
> My argument for using this notation stems from the fact that it would
> be a royal pain to write subs like:
>
> sub add ($a, $b) {
> $RET = $a + $b;
> }
This sounds sensible to me -- not something I'd normally bother saying
(a surprisingly high number of the mails on this list sound sensible to
me), but I thought this could do with some deWarnockization ...
Smylers
> Therefore, the first syntax can be redefined to evaluate the code block
> and assign the result to $0.
Would you ever want to leave $0 unaltered? That's the only concern
which comes to mind.
> My argument for using this notation stems from the fact that it would
> be a royal pain to write subs like:
>
> sub add ($a, $b) {
> $RET = $a + $b;
> }
I think Pascal does something like this.
JEff
Absoultely: if you want side-effects while building the default parse
tree. But then you just use a regular {} block instead of a <{}> block.
Luke
Well, I've been thinking about this for a couple of weeks now, and
while I freely admit that "$0 =" is ugly, I also find that I dislike
using <...> for something that is not a pattern assertion, but a
side effect. Plus your proposed notation is almost as long as what
you're replacing. And I don't think it stands out visually enough
for its semantic weight.
: My argument for using this notation stems from the fact that it would
: be a royal pain to write subs like:
:
: sub add ($a, $b) {
: $RET = $a + $b;
: }
:
: Even though it's just a few extra characters. I don't want to think
: about replacing the current parse tree node, I just want the rule to
: represent a value. An assignment has little place there.
Then what you want is something like a "return" keyword, only it returns
from the rule rather than the closure:
rule list {
<?term> , <?list> { succeed make_node('list', $?term, $?list) }
| <?term> { succeed $?term }
}
Or whatever word you like there...
Alternately, you can get rid of the explicit $0 by saying
rule list {
<?term> , <?list> {.= make_node('list', $?term, $?list) }
| <?term> {.= $?term }
}
That at least removes the extraneous "noun" from your thinking, and
".=" can be read as a pure verb if you like. And if you don't like,
translating "succeed" to ".=" via a macro is left as an exercise for
the don't-liker.
Larry